全网最全的微服务链路追踪实践

您所在的位置：网站首页 › skywalking 调用链监控 › 全网最全的微服务链路追踪实践

全网最全的微服务链路追踪实践

2023-09-20 14:35| 来源: 网络整理| 查看: 265

我正在参加「掘金·启航计划」

链路追踪介绍

对于一个大型的几十个、几百个微服务构成的微服务架构系统，通常会遇到下面一些问题，比如：

如何串联整个调用链路，快速定位问题？

如何缕清各个微服务之间的依赖关系？

如何进行各个微服务接口的性能分折？

如何跟踪整个业务流程的调用处理顺序？

1. skywalking是什么 1.1 skywalking介绍

Apache Skywalking是一款开源的应用程序性能监控工具，旨在帮助开发人员和 DevOps 团队监控分布式应用程序的性能。它可以帮助用户了解应用程序的运行情况，并通过可视化图形和数据报告，提供实时的指标和分析。

Skywalking 支持多种语言和框架，包括 Java、Go、Node.js 和 Python。它使用分布式追踪技术来监控应用程序内部和外部的所有调用，从而获得关于应用程序性能的完整见解。

Skywalking 提供了一系列强大的功能，包括性能监控、故障诊断和调试、数据分析等。它还提供了警报功能，当发生重要的性能问题时，可以向开发人员和 DevOps 团队发送通知。

Skywalking 还具有很好的可扩展性，可以与其他应用程序性能监控工具，如 Grafana 和 Elasticsearch 集成，从而提供更加强大的监控和分析能力。

总之，Apache Skywalking 是一款功能强大且易于使用的应用程序性能监控工具。它可以帮助开发人员和 DevOps 团队更好地了解应用程序的运行情况，并在发生性能问题时及时采取行动。

官网：skywalking.apache.org/

下载：skywalking.apache.org/downloads/

Github：github.com/apache/skyw…

文档：skywalking.apache.org/docs/main/v…

中文文档：skyapm.github.io/document-cn…

1.2 链路追踪框架对比 Zipkin是Twitter开源的调用链分析工具，目前基于springcloud sleuth得到了广泛的使用，特点是轻量，使用部署简单。 Pinpoint是韩国人开源的基于字节码注入的调用链分析，以及应用监控分析工具。特点是支持多种插件，UI功能强大，接入端无代码侵入。 SkyWalking是本土开源的基于字节码注入的调用链分析，以及应用监控分析工具。特点是支持多种插件，UI功能较强，接入端无代码侵入。目前已加入Apache孵化器。 CAT是大众点评开源的基于编码和配置的调用链分析，应用监控分析，日志采集，监控报警等一系列的监控平台工具。

1.3 性能对比

模拟了三种并发用户：500，750，1000。使用jmeter测试，每个线程发送30个请求，设置思考时间为10ms。使用的采样率为1，即100%，这边与生产可能有差别。pinpoint默认的采样率为20，即50%，通过设置agent的配置文件改为100%。zipkin默认也是1。组合起来，一共有12种。下面看下汇总表：

从上表可以看出，在三种链路监控组件中，skywalking的探针对吞吐量的影响最小，zipkin的吞吐量居中。pinpoint的探针对吞吐量的影响较为明显，在500并发用户时，测试服务的吞吐量从1385降低到774，影响很大。然后再看下cpu和memory的影响，在内部服务器进行的压测，对cpu和memory的影响都差不多在10%之内。

1.4 Skywalking主要功能特性

1、多种监控手段，可以通过语言探针和service mesh获得监控的数据；

2、支持多种语言自动探针，包括 Java，.NET Core 和 Node.JS；

3、轻量高效，无需大数据平台和大量的服务器资源；

4、模块化，UI、存储、集群管理都有多种机制可选；

5、支持告警；

6、优秀的可视化解决方案；

2. SkyWalking环境搭建部署

skywalking agent和业务系统绑定在一起，负责收集各种监控数据。 skywalking oapservice是负责处理监控数据的，比如接受skywalking agent的监控数据，并存储在数据库中;接受skywalking webapp的前端请求，从数据库查询数据，并返回数据给前端。Skywalking oapservice通常以集群的形式存在。 skywalking webapp，前端界面，用于展示数据。用于存储监控数据的数据库，比如mysql、elasticsearch等。 2.1 下载 SkyWalking

下载：skywalking.apache.org/downloads/

目录结构

2.2 搭建SkyWalking OAP 服务

启动脚本bin/startup.sh

日志信息存储在logs目录

启动成功后会启动两个服务，一个是skywalking-oap-server，一个是skywalking-web-ui ： 8868

skywalking-oap-server服务启动后会暴露11800 和 12800 两个端口，分别为收集监控数据的端口11800和接受前端请求的端口12800，修改端口可以修改config/applicaiton.yml

skywalking-web-ui服务会占用 8080 端口，修改端口可以修改webapp/webapp.yml

server.port：SkyWalking UI服务端口，默认是8080；

collector.ribbon.listOfServers：SkyWalking OAP服务地址数组，SkyWalking UI界面的数据是通过请求SkyWalking OAP服务来获得；访问：http://x.x.x.x:8080/

页面的右下角可以中英文切换，可以切换选择要展示的时间区间的跟踪数据。

2.3 SkyWalking中三个概念

服务(Service) ：表示对请求提供相同行为的一系列或一组工作负载，在使用Agent时，可以定义服务的名字；

服务实例(Service Instance) ：上述的一组工作负载中的每一个工作负载称为一个实例，一个服务实例实际就是操作系统上的一个真实进程；

端点(Endpoint) ：对于特定服务所接收的请求路径, 如HTTP的URI路径和gRPC服务的类名 + 方法签名；

3. SkyWalking 接入微服务

3.1 linux环境—通过jar包方式接入

准备一个springboot程序，打成可执行jar包，写一个shell脚本，在启动项目的Shell脚本上，通过 -javaagent 参数进行配置SkyWalking Agent来跟踪微服务；startup.sh脚本：

#!/bin/sh # SkyWalking Agent配置 export SW_AGENT_NAME=springboot‐skywalking‐demo #Agent名字,一般使用`spring.application.name` export SW_AGENT_COLLECTOR_BACKEND_SERVICES=127.0.0.1:11800 #配置 Collector 地址。 export SW_AGENT_SPAN_LIMIT=2000 #配置链路的最大Span数量，默认为 300。 export JAVA_AGENT=‐javaagent:/usr/local/soft/apache‐skywalking‐apm‐bin‐es7/agent/skywalking‐agent.jar java $JAVA_AGENT ‐jar springboot‐skywalking‐demo‐0.0.1‐SNAPSHOT.jar #jar启动

启动日志

等同于

java ‐javaagent:/usr/local/soft/apache‐skywalking‐apm‐bin‐es7/agent/skywalking‐agent.jar ‐DSW_AGENT_COLLECTOR_BACKEND_SERVICES=127.0.0.1:11800 ‐DSW_AGENT_NAME=springboot‐skywalking‐demo ‐jar springboot‐skywalking‐demo‐0.0.1‐SNAPSHOT.jar

参数名对应agent/config/agent.config配置文件中的属性。

属性对应的源码：org.apache.skywalking.apm.agent.core.conf.Config.java

# The service name in UI agent.service_name=${SW_AGENT_NAME:Your_ApplicationName} # Backend service addresses. collector.backend_service=${SW_AGENT_COLLECTOR_BACKEND_SERVICES:127.0.0.1:11800}

我们也可以使用skywalking.+配置文件中的配置名作为系统配置项来进行覆盖。 javaagent参数配置方式优先级更高。

测试：访问你的微服务

3.2 windos环境—在IDEA中使用Skywalking

在运行的程序配置jvm参数，如下图所示：

-DSW_AGENT_COLLECTOR_BACKEND_SERVICES 可以指定远程地址，但是-javaagent必须绑定你本机物理路径的skywalking-agent.jar

3.3 Skywalking跨多个微服务跟踪

Skywalking跨多个微服务跟踪，只需要每个微服务启动时添加javaagent参数即可。

测试：

启动微服务mall-gateway，mall-order，mall-user ，配置skywalking的jvm参数

http://localhost:8888/user/findOrderByUserId/1

拷贝agent/optional-plugins目录下的gateway插件到agent/plugins目录

4. Skywalking持久化跟踪数据

默认使用的H2数据库存储 config/application.yml

4.1 基于mysql持久化:

修改config目录下的application.yml，使用mysql作为持久化存储的仓库

修改mysql连接配置

storage:

#选择使用mysql 默认使用h2，不会持久化，重启skyWalking之前的数据会丢失

selector: ${SW_STORAGE:mysql} #使用mysql作为持久化存储的仓库 mysql: properties: #数据库连接地址 jdbcUrl: ${SW_JDBC_URL:"jdbc:mysql://1ocalhost:3306/swtest"} #用户名 dataSource.user: ${SW_DATA_SOURCE_USER:root} #密码 dataSource.password: ${SW_DATA_SOURCE_PASSWORD:root}

注意：需要添加mysql数据驱动包，因为在lib目录下是没有mysql数据驱动包的，所以修改完配置启动是会报错，启动失败的。

添加mysql数据驱动包到oap-libs目录下

启动Skywalking

查看swtest数据库，可以看到生成了很多表。

说明启动成功了，打开配置对应的地址http://192.168.3.100:8080/，可以看到skywalking的web界面。

测试：重启skywalking，验证跟踪数据会不会丢失

5. 自定义SkyWalking链路追踪

如果我们希望对项目中的业务方法，实现链路追踪，方便我们排查问题，可以使用如下的代码

引入依赖

SkyWalking 工具类 ‐‐> org.apache.skywalking apm‐toolkit‐trace 8.4.0 5.1 @Trace将方法加入追踪链路

如果一个业务方法想在ui界面的跟踪链路上显示出来，只需要在业务方法上加上@Trace注解即可

5.2 加入@Tags或@Tag

我们还可以为追踪链路增加其他额外的信息，比如记录参数和返回信息。实现方式：在方法上增加@Tag或者@Tags。@Tag 注解中 key = 方法名； value = returnedObj 返回值 arg[0] 参数

@Trace @Tag(key = "list", value = "returnedObj") public List list(){ return userMapper.list(); } @Trace @Tags({@Tag(key = "param", value = "arg[0]"), @Tag(key = "user", value = "returnedObj")}) public User getById(Integer id){ return userMapper.getById(id); }

性能分析

skywalking的性能分析，在根据服务名称、端点名称，以及相应的规则建立了任务列表后，在调用了此任务列表的端点后。skywalking会自动记录，剖析当前端口，生成剖析结果，具体流程如图：

6. Skywalking集成日志框架

引入依赖

1.x ‐‐> org.apache.skywalking apm‐toolkit‐logback‐1.x 8.5.0

添加logback-spring.xml文件，并配置 %tid 占位符

${CONSOLE_LOG_PATTERN}

测试

Skywalking通过grpc上报日志（需要v8.4.0+）

gRPC报告程序可以将收集到的日志转发到SkyWalking OAP服务器上

logback-spring.xml中添加

%d{yyyy‐MM‐dd HH:mm:ss.SSS} [%X{tid}] [%thread] %‐5level %logger{36} ‐%msg%n

打开agent/config/agent.config配置文件，添加如下配置信息：

plugin.toolkit.log.grpc.reporter.server_host=${SW_GRPC_LOG_SERVER_HOST:192.168.3.100} plugin.toolkit.log.grpc.reporter.server_port=${SW_GRPC_LOG_SERVER_PORT:11800} plugin.toolkit.log.grpc.reporter.max_message_size=${SW_GRPC_LOG_MAX_MESSAGE_SIZE:10485760} plugin.toolkit.log.grpc.reporter.upstream_timeout=${SW_GRPC_LOG_GRPC_UPSTREAM_TIMEOUT:30}

以上配置是默认配置信息,agent与oap在本地的可以不配

agent配置信息大全

Skywalking UI效果

7. SkyWalking 告警功能

SkyWalking 告警功能是在6.x版本新增的，其核心由一组规则驱动，这些规则定义在config/alarm-settings.yml文件中。告警规则的定义分为两部分：

告警规则：它们定义了应该如何触发度量警报，应该考虑什么条件。

Webhook（网络钩子）：定义当警告触发时，哪些服务终端需要被告知

告警规则

SkyWalking 的发行版都会默认提供config/alarm-settings.yml文件，里面预先定义了一些常用的告警规则。如下：

过去 3 分钟内服务平均响应时间超过 1 秒。

过去 2 分钟服务成功率低于80%。

过去 3 分钟内服务响应时间超过 1s 的百分比

服务实例在过去 2 分钟内平均响应时间超过 1s，并且实例名称与正则表达式匹配。

过去 2 分钟内端点平均响应时间超过 1 秒。

过去 2 分钟内数据库访问平均响应时间超过 1 秒。

过去 2 分钟内端点关系平均响应时间超过 1 秒。

这些预定义的告警规则，打开config/alarm-settings.yml文件即可看到。

告警规则配置项的说明：

Rule name：规则名称，也是在告警信息中显示的唯一名称。必须以_rule结尾，前缀可自定义 Metrics name：度量名称，取值为oal脚本中的度量名，目前只支持long、double和int类型。详见Official OAL script Include names：该规则作用于哪些实体名称，比如服务名，终端名（可选，默认为全部） Exclude names：该规则作不用于哪些实体名称，比如服务名，终端名（可选，默认为空） Threshold：阈值 OP：操作符，目前支持 >、 TN + period这个阶段不告警。默认情况下，它和Period一样，这意味着相同的告警（在同一个Metrics name拥有相同的Id）在同一个Period内只会触发一次 message：告警消息 7.1 Webhook（网络钩子）

Webhook可以简单理解为是一种Web层面的回调机制，通常由一些事件触发，与代码中的事件回调类似，只不过是Web层面的。由于是Web层面的，所以当事件发生时，回调的不再是代码中的方法或函数，而是服务接口。例如，在告警这个场景，告警就是一个事件。当该事件发生时，SkyWalking就会主动去调用一个配置好的接口，该接口就是所谓的Webhook。

SkyWalking的告警消息会通过 HTTP 请求进行发送，请求方法为 POST，Content-Type 为 application/json，其JSON 数据实基于List

【本文地址】

全网最全的微服务链路追踪实践

全网最全的微服务链路追踪实践

今日新闻

推荐新闻